For Access Rights in values Enumeration do

Hi all,

I'm creating a DXL script to remove access rights to some attributes

this code works fine :

Permission P_all = read|create|modify|delete|control
Permission P_read = read
 
AccessRec = ar
 
    //put object Text in read only except for admins
        AttrDef ad = find(m, "Object Text")
        
        //disable inheritance
        err = specificVal(m,ad)
        if (!null err){
        errorBox(err)
        halt
        }
 
        for ar in values ad do
        {
                if(username ar == dbgroup) then err  = setVal(m,ad, P_all, username(ar))
                else err  = setVal(m,ad, P_read, username(ar))
                
                if (!null err){
                errorBox(err)
                halt
                }
        }

 


I want to do the same process for a enumeration type attribute, I get an error as I try to access the values access records:

 

 

 

if (!exists attribute "Change Proposal Status")
{
    AttrDef ad = create object type "ChangeProposalStatusenum" attribute "Change Proposal Status"
}
 
        //ad = find(m, "Change Proposal Status")
 
        //disable inheritance
        err = specificVal(m,ad)
        if (!null err){
        errorBox(err)
        halt
        }
 
//error on this line ->
        for ar in values ad do
        {                            
                if(username ar == dbgroup) then err  = setVal(m,ad, P_all, username(ar))
                else then err  = setVal(m,ad, P_read, username(ar))
 
                if (!null err){
                errorBox(err)
                halt
                }
        }



I can't find anything on Enumeration manipulations in the DXL help manual
How can I get access to the access record of the value of an Enumeration attribute ?

(i'm using DOORS 9.3)



 

 


SystemAdmin - Fri Nov 26 14:52:47 EST 2010

Re: For Access Rights in values Enumeration do
llandale - Mon Nov 29 11:09:11 EST 2010

You should state the error and the line and tell us what line that is.

If the attr already exists your code won't find it and so 'ad' is undefined. You should add "current = m" as the first line and uncomment "ad = find(m, "Change Proposal Status")" at about line 6, perhaps preceding it with 'else'. You -should- be getting an error at the 'specific' command.

For whatever its worth, this code should insure the current user is a member of the 'dbgroup' group. In any event, perhaps your 'dbgroup' lacks full RMCDA rights to that attribute, and YOUR rights are getting reset to READ before you set full RMCDA rights to 'dbgroup'; so when you try you lack the rights to do so. So have two loops, 1st set dbgroup to RMCDA and 2nd set to R all others.

Instead of a loop, I'd do this:
set the default access to RMCDA (default is a null name)
use unsetAllVal to remove all other accesses
setVal dbgroup to RMCDA
set the default access to R.

  • Louie

Re: For Access Rights in values Enumeration do
SystemAdmin - Mon Nov 29 12:23:36 EST 2010

Hello Louie,

First, Thank you for your answer.

This code in fact is just a fragment of a 400+ lines of code I'm making so I have juste copy/pasted some info to explain my problem. I saw later on I missed some info, but can't edit message once it's sent.
Yes, I have declared (Module m = current) at the top of my script.

Just to explain further more,

At some point in our process, we need to lock some attributes in a module (not all of them) to control changes - and we don't like the CPS features, so we want to create our own Change Proposal System.

My login have all powers (RMDCA) to this module, so I know the problem is not from accesses.

The real problem is the DXL compiler generates an error if I throw a "enumeration" type in the for loop
 

AccessRec ar
 //create any enumeration attribute
 AttrDef ad = create object type "Boolean" attribute "example"
 
 
//this line here generates the error -->
    for ar in values ad do
        {
                print "Hello World!"
                //do whatever I need to do with each ar
        }

 


If I throw a string/text/anything else in the for loop, I can have access to AccessRecords in the value tab of the Attribute definition.
but the enumeration type generates :

-E- DXL: <Line:346> incorrectly concatenated tokens
-E- DXL: <Line:346> incorrect arguments for (do)
-I- DXL: All done. Errors reported: 2. Warnings reported: 0.

In my example, I exposed only two groups, for simplicity but the if statement is a bit more complex and I don't want all users in Read only ( some have the rights to change the controled attributes )

This script will be use in all Modules, and they won't use the same group (we have different groups for all projects) so I prefer running some "if statements" in a for loop ratter then forcing a "setval" no matter what...
--
I'm pretty sure my problem is related to enumeration manipulation but the DXL guide is not very loquacious about it...

 

Re: For Access Rights in values Enumeration do
llandale - Mon Nov 29 18:53:15 EST 2010

SystemAdmin - Mon Nov 29 12:23:36 EST 2010

Hello Louie,

First, Thank you for your answer.

This code in fact is just a fragment of a 400+ lines of code I'm making so I have juste copy/pasted some info to explain my problem. I saw later on I missed some info, but can't edit message once it's sent.
Yes, I have declared (Module m = current) at the top of my script.

Just to explain further more,

At some point in our process, we need to lock some attributes in a module (not all of them) to control changes - and we don't like the CPS features, so we want to create our own Change Proposal System.

My login have all powers (RMDCA) to this module, so I know the problem is not from accesses.

The real problem is the DXL compiler generates an error if I throw a "enumeration" type in the for loop
 

AccessRec ar
 //create any enumeration attribute
 AttrDef ad = create object type "Boolean" attribute "example"
 
 
//this line here generates the error -->
    for ar in values ad do
        {
                print "Hello World!"
                //do whatever I need to do with each ar
        }

 


If I throw a string/text/anything else in the for loop, I can have access to AccessRecords in the value tab of the Attribute definition.
but the enumeration type generates :

-E- DXL: <Line:346> incorrectly concatenated tokens
-E- DXL: <Line:346> incorrect arguments for (do)
-I- DXL: All done. Errors reported: 2. Warnings reported: 0.

In my example, I exposed only two groups, for simplicity but the if statement is a bit more complex and I don't want all users in Read only ( some have the rights to change the controled attributes )

This script will be use in all Modules, and they won't use the same group (we have different groups for all projects) so I prefer running some "if statements" in a for loop ratter then forcing a "setval" no matter what...
--
I'm pretty sure my problem is related to enumeration manipulation but the DXL guide is not very loquacious about it...

 

You should routinely specify the current module before using commands that presume it, in this case add "current = m" before your ad = create. Yes, that's in addition to the routine "Module m = current" at the top of the script. Its possible the 'current' module has changed AFTER your DXL script started, such as if you followed a link somewhere to a module you open, and you end up attempting to create your attribute in some other module (greatfully ReadOnly).

So you are getting intepret errors. I don't. Is it possible you have declared 'values' elsewhere as a function or a variable? BING BING BING

I do get execution errors at the do loop because 'example' already exists and therefore the 'create' fails and therefore it returns a null AttrDef. You should check for its existence and ad = create it if not else ad = find it if so. Or attempt to ad=find it, if null ad then attempt to ad=create it, if null ad then stop this chore.

CPS becomes remotely tolerable once you can display what exactly a CP will do when applied; functions and scripts and reports needed. It tricky looking at the Using flags, getting the Source attr value and using diff to the Proposed values, but once working its well worth it to provide the Board an actual report of what will happen.

Even if you START with full RMCDA access, you can remove that access from yourself and then NO LONGER have RMCDA and cannot do more access chores to that attribute. Yes, someone else with RMCDA access can indeed lock you out easily on anything, by simply providing you specifically with R or None access. this sort of script is best run as the Administrator.

  • Louie

If this still fails, look up my profile and send me the script.

Re: For Access Rights in values Enumeration do
SystemAdmin - Tue Nov 30 08:20:49 EST 2010

Hi Louie,

Thank you very much, I found my problem...

Yes, some function to generate Dialog Boxes was redefining "values"....

my bad.